In the prior art, many message delivery systems exist which route messages between endpoints, such as between different applications or clients. The messages may be routed to destination endpoints based on topics, queues, characteristics of the message content or a combination of criteria such as a topic to queue mapping. In the case of a system that routes messages based on topics, there are publishing (or producing) clients that generate messages and subscribing (or consuming) clients that receive messages. A given client may act as both a producer (publisher) and a consumer (subscriber). When a publishing client creates a message it adds to it a topic. Destination endpoints are created by subscribing clients that have associated with them a series of subscriptions (or interests) that are used to attract messages to the subscribing client. Alternately subscriptions may be used to attract messages to a queue endpoint which one or more clients can connect to and receive messages. The topics are typically text strings that often contain sub-fields also known as hierarchical levels but, maybe also be numbers. Interests or subscriptions are of a similar form to the topics but, may contain regular expressions (also known as wild cards) or if the topics are in the form of numbers, the interests could be in the form of a range of numbers. If the messages are to be routed based on the message content then the subscriptions are in the form of regular expressions designed to match a portion of the content or an expression in a query language such as SQL or XPATH (if the message content is in XML format). The interests are gathered by the message delivery system and are used to determine which destination endpoint(s) should receive a copy of a particular message received from a publishing client in a process called matching. In the topic based message delivery system the process of matching involves comparing the topics of messages received from publishing clients to the interests gathered from subscribing clients or queues. A match to an interest is generated when the topic of the incoming messages falls within the regular expression(s) contained in the interest. The present invention is also applicable to systems that route messages based on the content of the message as described in U.S. Pat. No. 7,627,570 and U.S. Pat. No. 7,801,857 the contents of which are herein included by reference.
In the prior art it is common to have two types of queues to hold messages for delivery to subscribing clients: non-exclusive queues and exclusive queues.
With a non-exclusive queues, multiple subscribing clients can connect to or bind to the same queue at the same time, and the messages in the queue are distributed amongst the connected subscribing clients, using algorithms such as round-robin or any other such load sharing mechanisms. This allows a number of subscribing clients to share the workload of the queue, and offers scalability to increase the workload capability and also provides resilience, since there are a number of attached subscribing clients that can service the workload. If a given subscribing client fails, the workload will be shared among the remaining active subscribing clients.
With an exclusive queue, only one subscribing client at a time will receive messages from the queue. The first subscribing client to bind to an exclusive queue will receive all messages. In the preferred embodiment of the prior art, other subscribing applications are also allowed to bind to the same queue, but they will not receive any messages, but simply are on “standby”. If the first subscribing client disconnects from the queue, perhaps due to a failure of the client or the inter-connecting network, the next subscribing client that had previously bound to the queue will be selected and will become the exclusive recipient of messages from that queue. Such an arrangement is suitable for message flows which only allow a single subscribing client at a time to process the message flow. However, there is still a form of resilience, since if the current active subscribing client fails, another subscribing client, which is waiting will start to receive the messages in the queue.
If the message system of the prior art does not allow multiple subscribing clients to bind to an exclusive queue (with one active and the others in standby), then the alternative is to only allow one to bind (the active one), and reject the bind attempts to the queue for all other subscribing clients. Such rejected subscribing clients would have to poll in the background, i.e. attempt to re-bind to the queue on a timed basis. Alternatively, the clients could communicate amongst themselves to determine when another subscribing client needs to take over from the current active one. Such implementations provide a much slower recovery time due to polling rather than being event driven. Moreover, it greatly increases the complexity of the subscribing client application logic.
In prior art systems that offer queues and allows multiple subscribing clients to bind to the queue, with subscribing clients being active or inactive for message delivery, if a current active subscribing client fails, the system will automatically start delivering messages to the next selected subscribing client. However, in prior art systems there is no notification mechanism to the subscribing clients to tell them, upon binding to the queue, whether the subscribing client is active or not for message reception from the queue. Moreover, the subscribing client is not informed when it becomes active. Rather, it simply starts to receive message from the queue. The subscribing client has to infer it is now the active subscribing client when it receives the first message. However, it may need to take action long before it receives the first message when it is the active subscribing client, such as updating its state, notifying other entities, etc. When it becomes active, there may be no messages available for delivery at that time, and thus a significant amount of time may pass before the next message is available for delivery and thus informing the subscribing client that it is now active. Also, if a client has been selected to be active, but there is something wrong with the publisher(s) that are supposed to places messages into the queue, the client has no way of knowing. A lack of received messages could be due to the client not being selected as active, or because the publisher(s) are not functioning correctly and not producing messages, or the queue might be improperly configured and unable to receive messages (for example, the queue might be listening to the wrong set of topics). There is also no mechanism to inform an application that the message delivery system has decided for some reason, such as an administrative action, to stop delivering messages to the current active subscribing client and has selected a different client to be active.